A conventional ATM (Automated Teller Machine) or the like incorporates with a device referred to as a card reader in which reading and writing in a magnetic card or an IC card are performed. The card reader may be connected with a card collection and return module in which a card having been forgotten to take out by a user is collected and returned. Further, the card reader may be connected with a device such as an image reader or a card printer other than a card collection and return module. A card can be conveyed between two devices connected with each other through a conveying passage.
The two devices are commonly controlled by a host apparatus such as a built-in PC (Embedded Personal Computer). The host apparatus controls the two devices by executing control programs corresponding to the respective devices. In this case, an application providing a user interface or the like of an ATM uses an API (Application Programming Interface) which is capable of issuing a command of a standard specification. Therefore, even when either of the devices is changed, a common application can be utilized by only changing a device driver or a registry which directly controls the device. An example in which such two devices are controlled is described in Japanese Patent Laid-Open No. 2009-86832.
An example like a technique described in the above-mentioned Patent Literature of a card conveyance system 3 provided with two devices will be described below with reference to FIG. 9. The card conveyance system 3 shows a structural example in which a card collection and return module 20 is connected with an ATM incorporating with a card reader 10 which has been used in a market. When a card 40 is to be collected, the card 40 in the card reader 10 is required to be conveyed to the card collection and return module 20 between the card reader 10 and the card collection and return module 20. Further, on the contrary, a card 40 may be required to be conveyed from the card collection and return module 20 to the card reader 10. In a case of an object in a control program of a middleware, for example, in a case of OS (Operating System) of Windows (registered trademark) series, control of the conveyance can be realized by executing a service provider (hereinafter, referred to as an “SP”) corresponding to each device. However, when a card 40 is conveyed between two devices, there may occur a problem that the card 40 is not normally delivered between two devices by control of an “SP” of each device. A specific example will be described below.
In FIG. 9, the host apparatus 33 includes, as functional blocks, an application executing section 110 configured to execute an application for finance and a middleware executing section 123 configured to execute an API corresponding to a command of standard of CEN/XFS (Comite Europeen de Normalisation/eXtensions for Financial Services) which is a standard in an application for finance. The middleware executing section 123 includes a card reader class SP 213 corresponding to control of the card reader 10 and a card collection and return module class SP 223 corresponding to control of the card collection and return module 20. This is because that, when mounting is performed according to the API of the CEN/XFS standard like this example, the SPs respectively corresponding to the card reader 10 and the card collection and return module 20 are required to provide. Further, the card reader class SP 213 and the card collection and return module class SP 223 are respectively provided with DLLs 510 and 520 (Dynamic Link Library) for execution which are configured to execute different device drivers or the like.
In this example, the card reader class SP 213 corresponding to the CEN/XFS standard does not prepare a command that a card 40 is taken in from a rear side. Therefore, the host application executing section 110 is unable to send a command to the card reader 10 for taking in a card 40 from a rear side. Accordingly, a card 40 conveyed from the card collection and return module 20 is stopped in a state that the card 40 has been pushed into a rearward insertion port of the card reader 10. On the other hand, the card reader class SP 213 is provided with a reset command for resetting the card reader 10 and an ejection command for ejecting a card 40 existed in an inside of the card reader 10 to a gate insertion port. Therefore, the card 40 having been pushed into the rear side of the card reader 10 from the card collection and return module 20 is ejected to the gate port where the card 40 is to be inserted by a user by using these commands and the card is returned to the user.
However, when a card 40 is conveyed according to the above-mentioned method, the card 40 is unable to be smoothly conveyed between the two devices. Therefore, the conveying roller 11 located on a rear side of the card reader 10 and the conveying roller 21 which is used in the card collection and return module 20 for ejecting the card 40 are remarkably deteriorated. This problem occurs similarly when a card 40 is conveyed in the opposite direction, in other words, when a card 40 is conveyed from the card reader 10 to the card collection and return module 20.